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Abstract. The systems engineering of space missions to study planet Earth has 
been an important focus of the National Aeronautics and Space Administration 
(NASA) since its inception. But all space missions are becoming increasingly 
complex and this fact, reinforced by some major mishaps, has caused NASA to re- 
evaluate their approach to achieving safety and mission success. 

A new approach ensures that there are adequate checks and balances in place to 
maximize the probability of safety and mission success. To this end the agency 
created the concept of Technical Authority which identifies a key individual 
accountable and responsible for the technical integrity of a flight mission as well as a 
project-independent reporting path. At the Goddard Space Flight Center (GSFC) this 
responsibility ultimately begins with the Mission Systems Engineer (MSE) for each 
satellite mission. 

This paper discusses the Technical Authority process and then describes some 
unique steps that are being taken at the GSFC to support these MSEs in meeting 
their responsibilities. 

Introduction. NASA programs and projects have directly contributed to 
characterizing and analyzing the Earth’s land-masses, oceans and atmosphere from 
the planet’s surface to space since the formation of the agency in 1958. 
One significant example of this is the Landsat program which consists of a series of 
Earth-observing satellite missions jointly managed by NASA and the U.S. Geological 
Survey. Since 1972, Landsat satellites have collected information about Earth from 
space. The science of remote sensing has matured with the multispectral images of 


the Landsat program. Landsat satellites have provided global coverage of Earth’s 
continents and surrounding coastal regions for over three decades, enabling 
scientists to study the many aspects of our planet and to evaluate the dynamic 
changes caused by both natural and human processes. 

Missions since Landsat have become even more complex. Hardware and software 
are integrated into platforms with autonomous capabilities that were only dreamed of 
a decade ago. The challenge of engineering these systems to meet cost, schedule 
and performance requirements within acceptable levels of risk has become more 
difficult. In recent years this has resulted in an engineering excellence initiative within 
the agency, one of the outcomes of which has been a revitalization of systems 
engineering. 


Technical Authority 

As part of the effort to achieve engineering excellence, the agency took steps to 
ensure that there are adequate checks and balances in place to maximize the 
probability of safety and mission success. To this end the agency created the 
concept of Technical Authority which identifies a key individual accountable and 
responsible for the technical integrity of a flight mission. A fundamental part of the 
Technical Authority concept is that it has provided for an engineering reporting path 
up through the organization which is independent of the project. 

Previously when the systems engineering team identified a serious technical risk they 
had to work with the project manager to eliminate or mitigate that risk. Often the 
project manager, under cost and schedule pressures, would not approve the 
recommended technical solution, choosing instead to either accept the risk or 
implement only part of the recommended solution. The technical team had nowhere 
to appeal the decision. The project manager's decision was final. 

At the same time there already existed an independent reporting path for the project 
system assurance managers (SAMs) up through the Office of System Safety and 
Mission Assurance. If the SAM discovered something that was not safe he/she did 
not have to go through the project manager. The SAM could go around the project 
directly up through his or her organization and ultimately to the agency administrator, 
if necessary. 

This was considered to be a good model for the technical team as well. So in 
February 2006 the agency took a major step and issued an interim policy establishing 
the organizational independence of technical authority from programs and projects. 
As a result the lines of technical authority were now independent from, yet equal to, 
the programmatic lines of authority. The policy was later codified with the release of 
an updated NASA Program and Project Management Processes and Requirements 
Policy document (NASA 2007a). 

Each of the ten NASA field centers is developing a Technical Excellence 
Implementation Plan describing the Center’s implementation of the Technical 


Authority. Under this plan each Center Director will select a systems technical 
authority for each program and project at the Center. For example, this would be a 
chief engineer, systems engineer, or lead engineer who will exercise technical 
authority for that program or project. In addition, the plan specifies that the systems 
technical authority will reside in an engineering organization and be matrixed to 
support the program or project, coordinating all the engineering activities including 
discipline engineers. 

Furthermore, the Center Director, or his/her designee, will appoint appropriate lead 
discipline engineers to serve as the technical authority for that discipline and all the 
engineers for that discipline will report to that individual. In other words, there will be 
a lead thermal engineer, for example, that will be the technical authority for the 
thermal engineering on the project and all the thermal engineers on the project will 
report to him or her. 

All program and project managers are responsible for implementing the technical 
authority requirements on their program or project. 
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Figure 1 - Reporting and Technical Authority at GSFC 

Balance between Program/Project Management, Engineering and System Safety and Mission Assurance 


Figure 1 illustrates the implementation of the independent Technical Authority path at 
the Goddard Space Flight Center shown in green (NASA 2006). Note that there are 
actually three paths to the NASA Administrator shown in this diagram: 

(1) Engineering (Technical Authority) 

(2) Program and Project Management 

(3) Safety and Mission Assurance 









It is the flow paths for technical and programmatic authority that are of interest here. 
The reporting path for Safety and Mission Assurance has been in place for many 
years and has been successfully resolving issues involving mission safety, quality 
and reliability. However, many technical issues fall strictly within the purview of 
systems engineering and are beyond the domain of Safety and Mission Assurance. 

The other two flow paths for technical and programmatic authority illustrated in Figure 
1 are clearly separate. The programmatic authority flows from the Mission 
Directorate at NASA Headquarters to the program and project managers assigned to 
the Center. The Technical Authority, on the other hand, flows from the NASA Chief 
Engineer to the Center Director. From there it flows down to the Director of 
Engineering, the Division Chiefs, and ultimately to the lead systems engineer on the 
program or project. Only those individuals in positions with formally delegated 
Technical Authority can exercise Technical Authority. 

Although the project manager and the lead systems engineer have separate reporting 
paths for dissenting opinions, they must work together as a team to achieve technical 
excellence and mission success. Each must understand the other’s position while 
recognizing the other’s right to appeal. They must work together to try and resolve 
issues before they are reported up to higher authority. 

If the lead systems engineer must appeal a decision of the project manager he must 
do it in a way which is viewed as maintaining the technical integrity of the project 
rather than a personal confrontation. The process of handling dissenting opinions is 
based on personal responsibility to adhere to the agency’s shared core values of 
safety, teamwork, integrity, and mission success. 

Clearly, the responsibility for technical authority ultimately falls on the shoulders of the 
lead systems engineer since he/she is closest to the day-to-day engineering effort. It 
is the goal of the Mission Systems Engineering Branch to assist these lead systems 
engineers in the execution of their responsibilities. There are 26 programs and 
projects at the Goddard Space Flight Center to which technical authority has been 
delegated. This gives a feel for the efficiency of scale that can be achieved with any 
assistance that can be given to the lead systems engineers or Mission Systems 
Engineers (MSE). 

Flow of Technical Requirements. Along with the downward flow of technical 
authority there is a similar downward flow of technical requirements as illustrated in 
Figure 2. There are several sources of requirements: there are those that originate 
with the Office of the Administrator and the Office of Chief Engineer at NASA 
Headquarters and flow down to the Center Director (CD) [bold solid line]; there are 
institutional requirements that originate with the Center Director and flow down 
through engineering to the Lead System Engineer (LSE) and the Lead Discipline 
Engineers (LDE) supporting the programs and projects [bold dashed line]; and, finally, 
there are derived requirements that are generated within the project itself as a joint 
effort between the project manager and the lead systems engineer [narrow solid line]. 


Technical issues can arise from any of these requirements. It is the responsibility of 
the lead system engineer or MSE to be aware of all the requirements that affect 
his/her program or project and to ensure that each requirement is satisfied and 
verified. If a particular requirement does not pertain to his/her particular project then it 
is the responsibility of the MSE to obtain a waiver from the appropriate level of 
authority from which the requirement was issued. 

Just becoming familiar with the sheer number of requirements contained in all the 
requirement documents is a tremendous burden to the MSEs. On top of that is the 
question of which requirements apply to which phase of the lifecycle. Some 
requirements apply to the early project formulation phases and others apply to the 
implementation phases. The requirements traceability tool presented later in this 
paper is an attempt to assist the MSE in satisfying all the requirements according to 
their lifecycle phase.. 

But first, it will be helpful to study an actual example where technical authority was 
exercised in order understand the difficult position that the MSEs are in and why they 
must exercise true systems thinking and be aware of all the requirements which affect 
their projects. We will next examine what was done to understand the enablers and 
barriers to systems thinking - a critical first step in assisting the MSEs in executing 
their responsibilities. And finally we will discuss the development of the requirements 
traceability tool. 



Figure 2 - Flow of Technical Requirements and Associated Challenges 








Exercising Technical Authority 

To understand the heavy responsibility and pressures on someone serving as 
Technical Authority we consider an actual flight mission example 1 that exhibits the 
enablers and barriers encountered in the role of the Technical Authority. 

The situation is a weather satellite on the launch pad at Cape Kennedy. This satellite 
is a national asset critical to early detection and tracking of major storms. Failure of 
such an asset could possibly result in the loss of hundreds of lives and billions of 
dollars in property. 

The Director of Engineering at Goddard Space Flight Center contacts the Mission 
Systems Engineer who is the Technical Authority on the project and asks him if the 
mission is ready for launch and if everyone is in agreement with the launch decision. 
These questions arise from the Agency Governance Model which enables the 
Technical Authority to exercise an appeals process to upper management outside the 
program/project chain of authority. In addition, the Governance Model reduces 
barriers that tended to isolate engineers from voicing concerns relative to program 
decisions based upon technical content. 

For the case at hand, we will focus on one issue that has arisen that the Technical 
Authority must resolve prior to announcing to the Director of Engineering that the 
mission is a go. One of the launch vehicle components is a Composite Overwrapped 
Pressure Vessel (COPV). The COPV is qualified for a design life of 30 cycles to 5000 
psi. The inner metallic liner of the vessel is prone to buckling however and requires 
regular, routine, inspection to confirm acceptability for flight. Following a non- 
destructive examination (NDE), a test article was cycled 7 times to 5000 psi without 
evidence of buckling. By NASA Goddard standards, this means that the tank life is 
based upon 7 cycles. In addition, the requirement on the factor of safety for cycle life 
is 4, so that the tank has a cycle life of 7/4 or 1 .75 cycles. The project engineers take 
the conservative position that the actual cycle life is 1 , since allowable cycle life is an 
integer and the 1.75 figure should be rounded down to 1, not rounded up to 2. 
Basically, if factors of safety are not respected, why have them? Exercising the 
prerogative of the propulsion branch, which is the technical discipline organization 
responsible for pressure vessels such as this, the Technical Authority is informed that 
there is only one opportunity to launch the satellite. 

The Technical Authority (TA) now has a written statement from engineering stating 
that there is a single launch opportunity for this mission. Knowing that the TA must 
answer to the Director of Engineering with regard to launch readiness as well as any 
dissenting opinions, we will review the surrounding circumstances and many inputs 
that the TA must consider in this decision. 

First, the TA knows, from discussions with the project office and engineering that the 
COPV is pressurized 20 minutes before launch, or time of launch minus 20 minutes 

1 This example is attributed to a Mission Systems Engineer and Technical Authority. 


(T-20 minutes). If the mission is aborted within the 20 minutes of launch, and the 
allowable number of cycles is 1, the tank must be left pressurized until the next 
launch attempt. This situation can easily arise at Cape Kennedy, for example, as a 
result of a sudden, fast-moving, thunderstorm. Since the tank has not been qualified 
for a long hold time, this is not acceptable. If the tank is depressurized until the next 
launch opportunity, the tank will be into its second cycle. 

The TA is also aware, from discussions with the project office, that there is a 3-day 
launch window and that the cost of delay is $200K per day. If the 3-day launch 
window is missed, the next launch cannot be attempted for 45 days due to other 
missions in the launch queue. The potential cost of delay is now $9M. 

The TA is under pressure for a launch go-ahead from the project office. Also, the 
project office wants to have two launch opportunities during the 3-day launch window. 
At the same time, the Program Office, although believing that there is small inherent 
risk to the launch, does not want to establish an a priori waiver that will establish a 
precedent for other, future, programs. It is considering a recommendation to abort 
the launch and then process a waiver to allow the launch so that this becomes a one- 
time exception, not a precedent. Engineering is taking the position that 1 .75 cycles 
should be treated as one cycle, not two. A contractor expert supporting the project 
sees a small inherent risk but says that the mission should be given the broadest 
possible window and a launch go-ahead should be authorized. The contractor 
provides his own safety analysis but basically says that he will do whatever the 
government directs. Finally, the TA gets another call from the Director of Engineering 
with the question: “What is your recommendation if we scrub the launch today 
(assuming the T-20 minute window is passed and the system is pressurized) should 
we attempt to launch tomorrow?” 

With the information at hand, the TA decided in favor of recommending a mission 
launch. No one disagreed that the system could certainly withstand one launch cycle. 
Only if the launch were aborted would the number of system cycles become an issue. 
In this case, the launch was authorized and, as it turned out, was successful. In 
discussions with the TA, it was clear that a second launch would have been 
recommended during the 3-day launch window if it were necessary. The Missed 
Opportunity of missing the launch window, in terms of satellite unavailability and cost 
impact, overcame the “small inherent risk” to launch. 

Although this example had a successful conclusion, it illustrates the difficulties facing 
the TA in making a decision, and that decision would not have been as easy if the 
satellite did not launch on the first attempt. Facing the issues of uncertainty, conflict, 
ambiguity, stress and high stakes consequences, the TA must exercise system 
thinking. System thinking allows the TA to see beyond the dissenting opinions of the 
discipline engineering organization, which was following the strict letter of the 
requirement. They insisted on a safety factor of 4, and rightly so, since they are 
bound by the requirements imposed on their discipline. But system thinking takes in 
the big picture and considers all aspects and consequences of the situation and 


weighs the requirement against the risk: what is the probability of occurrence and 
what are the consequences? But how does one develop system thinking? What are 
the enablers and barriers to system thinking within an organization? The Mission 
Systems Engineering Branch attempted to answer these questions. 


Development of Critical System Thinking: Enablers and Barriers 

As described in the previous sections, the mission systems engineers are responsible 
for increasingly complex missions. In order to better understand of how to develop 
qualified senior systems engineers to satisfy NASA satellite mission needs, the 
Mission Systems Engineering Branch at the Goddard Space Flight Center 
collaborated with industry and academia regarding the practices and methods by 
which senior systems engineers are best prepared for their roles. In December 2006, 
the branch established an agreement with Professor Donna Rhodes from the MIT 
Lean Advancement Initiative (LAI) (formerly known as the Lean Aerospace Initiative) 
to perform surveys on the enablers and barriers in the development of systems 
thinking in engineers at Goddard. This effort was to extend Dr. Heidi Davidz’s 
doctoral dissertation on the same subject (Davidz 2005). In January 2007 a Masters 
Degree candidate at MIT performed a one-month study at Goddard using interviews 
and surveys based on Dr. Davidz’s technique. This technique involved a carefully 
constructed question set that had been used to investigate system thinking at ten 
aerospace companies. The results of this technique applied to our branch provided 
us a unique opportunity to reflect on our practices of systems engineer development 
(Adams 2007). 

As shown in numerous research findings, system thinking is one of the key attributes 
of a successful systems engineer. Our MIT study goal was first to understand how 
our senior systems engineers with proven track records actually developed their 
system thinking. The second goal was to understand and eliminate the obstacles that 
prevent our engineers from developing such thinking. One of the key questions used 
in the interviews was, “What enablers or barriers have you seen to the development 
of systems thinking in engineers?” 

In terms of barriers, 42 percent of those surveyed said that being too detail-oriented 
could be a barrier. 12 percent indicated that lack of interest on the part of engineers 
to become systems engineers was a barrier and 3 percent indicated that limited 
exposure to systems engineering was a barrier. Meanwhile five engineers said that 
organizational culture was an important factor and could be a barrier. From the 
responses of the interviews, it seems that the barriers to the development of systems 
thinking within our organization are largely intangible. 

In terms of enablers, 30 percent of those surveyed said that exposure to how 
subsystems interact was a key enabler. 27 percent indicated that systems 
engineering training programs such as our internal Systems Engineering Education 
and Development (SEED) program are enablers. Another 21 percent indicated that 


mentoring programs were strong enablers. Our interview results align well with the 
results obtained from interviews at the aerospace companies described in Dr. 
Davidz’s original work, particularly in the areas of experience, exposure to how things 
interact and training. 

During the interviews, our engineers indicated a number of personal characteristics 
that seem to favor the development of system thinking in an individual. Such 
characteristics as curiosity, big picture thinking, good personal interaction with people, 
open mindedness, good communication, and understanding (or wanting to 
understand) how systems interact are the individual characteristics that seem to 
predict the development of systems thinking. 

Based on the interview results, our immediate focus was to increase our engineers’ 
exposure to a variety of mission activities. For example, we have worked diligently to 
ensure that each of our systems engineers serves on a peer review panel for a 
mission in addition to the mission that he/she is working on. That allows them the 
opportunity to see how other projects deal with problems and what unique processes 
work for them. We also established small mission focus groups so that the engineers 
can share their knowledge and experience among themselves. And finally, we 
organized systems engineering seminars once a month to expose the engineers to a 
broad range of systems engineering experiences both inside and outside of the 
agency. Although this is just a start, they are important steps in broadening the 
system thinking view of the systems engineers who serve as Technical Authority. 

Systems Engineering Requirements Traceability 

Earlier we addressed the new Technical Authority model invoked at NASA and the 
complexities associated with its application. The impact of the new TA can be 
visualized if one considers that there are 64 Mission System Engineers (MSEs) at 
Goddard of which 18 have Technical Authority responsibilities in their specialties. 
These MSEs provide support for over 20 space mission projects at any given time. 
The MSE function supports the Program/Project Managers and assures the program 
office that all Systems Engineering requirements are satisfied at the Program/Project 
Milestone Reviews. As a result the Mission Systems Engineering Branch at Goddard 
has undertaken the task of seeking ways to ease the burden of day-to-day pressures 
placed on the MSE wherever possible so that the MSE can focus attention on broader 
systems engineering issues, including TA responsibilities. 

The flow of requirements imposed upon the MSE is depicted in Figure 3. This depicts 
how the generic flow of Figure 2 is specifically applied to the systems engineering 
effort at Goddard. The parent document for Systems Engineering is the agency 
Systems Engineering Processes and Requirements NPR 71 23.1 A (NASA 2007b). In 
turn, the requirements of the NPR are implemented by the individual NASA Centers 
which in the case of Goddard results in the Goddard Procedural Requirements for 
Systems Engineering GPR 7120. 5A. In addition to the GPR 7120.5A, requirements 
are imposed upon the MSE from other documents described in Figure 3 covering 


areas such as risk management, engineering peer reviews, Rules for the Design, 
Development, Verification and Operation of Flight Systems (known as the “GOLD 
Rules”) and Integrated Independent Review Guidance. In general, requirements 
contained in the referenced documents have shortcomings with regard to their 
application by the MSE. The stated requirements typically are not directly tied to the 
project life cycle phases, the activities that are conducted to meet the requirements 
are not delineated and the requirements that are the responsibility of the MSE are not 
identified as such. In order to correct these limitations the GSFC Mission Systems 
Engineering Branch has undertaken the development of a System Engineering 
Requirements Traceability (SERT) tool to aid the MSE. 

The objectives for the SERT tool were derived from several senior systems engineers 
within the branch: 

(1) Provide a mechanism to link the agency NPR 7123 requirements to the 
Goddard Systems Engineering GPR 7120. 5A as part of the implementation of the 
NPR as mandated by the NASA Office of the Chief Engineer. 

(2) Develop a process to generate, distribute, and update traceability of systems 
engineering compliance matrices from NASA Procedural Requirements to Goddard 
Procedural Requirements to flight project requirements. 

(3) Satisfy GSFC requirements management principles, namely, “ A requirements 
management process shall be developed throughout the lifecycle that includes 
requirements identification, tracking, and documentation as well as a flow-down and 
traceability of Level 1 requirements to implementation requirements.” (GSFC 2006) 

(4) Provide a tool to assist lead systems engineers, as the Technical 

Authority, in readily identifying and complying with all NASA and GSFC requirements. 

(5) Locate all MSE requirements in one place with references to their source. 

(6) Make requirements traceable from the agency NPR 7123.1, the GSFC GPR 
7120.5A and other relevant Goddard Procedures and Requirements. 

(7) Categorize requirements and the activities associated with the requirements by 
mission lifecycle phase. 

(8) Design the SERT tool with an open architecture that will permit ease of expansion 
to incorporate future additions of Goddard MSE requirements documents and new or 
revised agency NPRs. The SERT tool should be able to accommodate added 
capabilities such as links to templates for such things as the Systems Engineering 
Management Plan (SEMP). 



The SERT tool is first intended to provide value added to the Mission Systems 
Engineer by reducing the time expended by the MSE in identifying the complete set of 
systems engineering requirements for a project. Secondly, the tool reduces the 
frequency of errors of omission due to missed requirements. Thirdly, having a handle 
on all the requirements will enable the MSE to provide better support for the project 
major milestone reviews and the systems engineering peer reviews and will permit 
early identification and resolution of requirement issues. Fourthly, the Technical 
Authority can get an early look at which requirements drive the design and also which 
requirements are not applicable and may need a waiver. Finally, the SERT tool 
provides for traceability of requirements among documents and between agency and 
the Center procedures and requirements which aids the verification and validation 
process. 

The SERT tool uses the CORE ® software tool 2 to provide requirements traceability 
and to satisfy the above requirements. Using CORE ® and navigating the SERT 
database, the MSE is able to extract information by sorting data as follows: 

a. Requirements by project life cycle phase 

b. Activities by project life cycle phase 

c. Requirements by document 

d. Complete documents (from the “Reference Library”) 


The NASA project lifecycle appears as Figure 4. GSFC has incorporated a systems 


2 CORE is a registered trademark of Vitech Corporation 
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1 Flexibility is allowed in the timing, number, and content of reviews as long as 

the equivalent information is provided at each KDP and the approach is fully 
documented in the Project Ran. These reviews are conducted by the project 
for the independent SRB. See Section 2 5 and Table 2-6. 

2. PRR Needed for multiple ( ^4) system copies. Timing is notional 

3. CERRs are established at the discretion of Program Offices. 

4 For robotic missions the SRR and the MDR may be combined. 

5. The ASP and ASM are Agency reviews, not life-cycle reviews 

6. Includes recertification, as required 

7 Project Plans are baselined at KDP C and are reviewed and updated as 

required, to ensure project content, cost, and budget remain consistent 


ORR — Operational Readiness Review 
PDR — Preliminary Design Review 
PFAR — Post-Flight Assessment Review 
PLAR — Post-Launch Assessment Review 
PNAR — Preliminary Non-Advocate Review 
PRR— Production Readiness Review 
SAR — System Acceptance Review 
SDR — System Definition Review 
SIR— System Integration Review 
SMSR — Safety and Mission Success Review 
SRR — System Requirements Review 

NAR — Non-Advocate Review 


ASP— Acquisition Strategy Planning Meeting 

ASM — Acquisition Strategy Meeting 

CDR — Critical Design Review 

CERR — Critical Events Readiness Review 

DR — Decommissioning Review 

FAD— Formulation Authorization Document 

FRR — Flight Readiness Review 

KDP — Key Decision Point 

LRR — Launch Readiness Review 

MCR— Mission Concept Review 

MDR— Mission Definition Review 


Figure 4 - The NASA Project Life Cycle (Showing the SE Peer Reviews) 
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Figure 5 - GOLD Rules Activities Example 
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Figure 6 - CORE User Interface for SERT 


Prior to loading the SERT database it is necessary to review the documents listed in 
Figure 3 and identify the requirement statements, corresponding project life cycle 




phase and determine if the requirement is applicable to the MSE function. 

The final important input to the SERT database is the distribution of activities which 
are performed by the MSE according to life cycle phase for a particular GPR or 
Standard. Figure 5 provides an example of this input for the GSFC “GOLD Rules” 
Standard. 

With all inputs identified as shown in the above figures and tables, the MSE 
requirements data is loaded into the SERT tool using the CORE ® software. Figure 6 
shows the CORE user interface for the SERT. As developed, the SERT tool can be 
navigated to satisfy the objective of providing the MSE immediate access to all 
requirements and activities imposed by the governing Center documents across the 
lifecycle phases of a GSFC project. 

Summary 

Faced with the new role as Technical Authority for a program or project, the Mission 
Systems Engineer has taken on serious responsibilities that demand a solid 
foundation in system thinking and a firm grasp of all the requirements levied on his 
mission. The home organization, the Mission Systems Engineering Branch, has 
taken steps to first understand the enablers and barriers to system thinking and then 
to provide assistance to the MSEs in developing system thinking. In addition the 
branch has developed a tool to assist the MSE in navigating and tracing all the 
applicable requirements both by document and by lifecycle phase. 
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